Voice over internet protocol (VolP) location based 911 conferencing

ABSTRACT

Voice Over Internet Protocol (VoIP) emergency calls to an Emergency Response Center (ERC) are handled through a VoIP conference bridge on a VoIP service provider&#39;s soft switch. The soft switch works with a VoIP positioning center (VPC) to obtain location information, which is compared against a PSAP database to find an initial best-appropriate PSAP for the location of the emergency caller. The PSAP is issued an Invite message to join the conference, establishing an emergency call. Third parties such as police, ambulance may be issued Invite messages to join the conference. Cold transfers are avoided by Inviting participants to join a single emergency conference rather than passing an emergency call from party to party (e.g., from PSAP to police to ambulance, etc.) The PSAP, other emergency responders, and even the initial VoIP emergency caller may leave and rejoin the VoIP conference without dropping the conference between the others.

This application is related to and claims priority from a co-pendingU.S. Provisional Application No. 60/723,960, entitled “Voice OverInternet Protocol (VoIP) Location Based Conferencing”, filed on Oct. 6,2005; U.S. Provisional Application No. 60/733,789, entitled “Voice OverInternet Protocol (VoIP) Multi-User Conferencing”, filed on Nov. 7,2005; and U.S. Provisional Application No. 60/723,961, entitled “VoiceOver Internet Protocol (VoIP) Location Based 911 Conferencing”, filed onOct. 6, 2005; the entirety of all three of which are expresslyincorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to Voice Over Internet (VoIP) protocolsand architectures. More particularly, it relates to location basedservices for the provision of 911 emergency services using VoIPprotocols and architectures.

2. Background of the Related Art

911 is a phone number widely recognized in North America as an emergencyphone number that is used by emergency dispatch personnel, among otherthings, to determine a location of a caller. Enhanced 911 (E911) isdefined by the transmission of callback number and location information.E911 may be implemented for landline and/or wireless devices.

A Public Safety Answering Point (PSAP) is a dispatch office thatreceives 9-1-1 calls from the public. A PSAP may be a local, fire orpolice department, an ambulance service or a regional office coveringall services. A 9-1-1 (“911”) service becomes E-9-1-1 (“E911”) whenautomatic number identification and automatic location information froma communications device (e.g. wireless phone, VoIP Phone, etc.) isprovided to the 911 operator.

Voice-Over-Internet Protocol (VoIP) is a technology that emulates aphone call, but instead of using a circuit based system such as thetelephone network, utilizes packetized data transmission techniques mostnotably implemented in the Internet. 911 calls made using VoIPtechnology must reach the correct PSAP, but there currently is nouniform interface to the various PSAPs for call delivery because thetechnology for connecting calls varies. For instance, not all PSAPs areInternet Protocol (IP) capable. Some PSAPs are accessed via ordinarypublic switched telephone network (PSTN) telephone lines. Some PSAPs areaccessed through selective routing such as direct trunks. Still otherPSAPs are accessed using IP connections. There is no uniformity amongthe thousands of different PSAPs.

Moreover, some Public Safety Access Points (PSAPs) are not enhanced, andthus do not receive the callback or location information at all from anyphone, landline or wireless.

The use of VoIP technology is growing quickly. As people adoptvoice-over-IP (VoIP) technology for routine communications, theinventors herein recognize that there is a growing need to access E911services including provision of location information from a VoIP device.

The existing E911 infrastructure is built upon copper wire line voicetechnology and is not fully compatible with VoIP. Given VoIP technology,there are at least three VoIP scenarios:

-   -   1. A VoIP UA that is physically connected to a static data cable        at a “home” address. For instance, an Analog Telephone Adapter        (ATA) that is connected to the “home” data cable and uses        traditional telephone devices.    -   2. A VoIP UA that is physically connected to a data cable at a        location different than its “home” address. For instance, a        laptop computer device utilized away from home as a VoIP        software telephone would be a VoIP ‘visitor’ device as described        by this scenario.    -   3. A VoIP UA that is wireless, physically disconnected from any        data cable. In this situation, the VoIP UA connects to the VoIP        service provider via either a wide-area wireless technology        (e.g., cellular, PCS, WiMAX) or via a local-area wireless        technology (e.g., Wireless Fidelity (WiFi), UWB, etc.) using a        laptop computer or handheld device.

VoIP phone calls are routed to a VoIP voice gateway, from which they arepassed on to their destination. A VoIP voice gateway or soft switch is aprogrammable network switch that can process the signaling for all typesof packet protocols. Also known as a ‘media gateway controller,’ ‘callagent,’ or ‘call server, such devices are used by carriers that supportconverged communications services by integrating SS7 telephone signalingwith packet networks. Softswitches can support, e.g., IP, DSL, ATM andframe relay.

The challenges evident with respect to determining the location of acalling VoIP telephone is perhaps most evident with respect to its useto make an emergency call (e.g., a 911 call). Nevertheless, VoIPtelephone technology is quickly replacing conventional switchedtelephone technology. However, because VoIP is Internet Protocol (IP)based, call related information such as CallerID type services may notbe available or accurate. A location of a given VoIP device may beprovisioned to be at a given geographic location, or queried from a homelocation register (HLR) in a mobile system.

In addition, some Public Safety Access Points (PSAPs) are not enhanced,and thus do not receive the callback or location information at all fromany phone; landline, cellular or VoIP.

Moreover, there is complexity in public access to Public SafetyAnswering Points due to lack of a Session Initiation Protocol (SIP)Uniform Resource Identifier (URI) for all PSAPs. (SIP is the IP-basedprotocol defined in IETF RFCs 3261 and 2543.) SIP is one of two dominantprotocols used by the VoIP industry. URI is the addressing technologyfor identifying resources on the Internet or a private intranet. URIswere originally defined as two types: Uniform Resource Locators (URLs)which are addresses with network location, and Uniform Resource Names(URNs) which are persistent names that are address independent. Today, aURI is defined by its purpose rather than the URL vs. URNclassification.) Some PSAPs are accessed only by conventional telephoneline, others only by direct telephone trunk lines. Not all PSAPs areaccessible via the Internet.

FIG. 5 shows basic conventional VoIP elements required to interconnect aVoIP emergency E911 caller to a relevant public safety access point(PSAP).

In particular, as shown in FIG. 5, VoIP telephone devices 102 a, 102 b,102 c (collectively referred to as 102) are connected to respective VoIPService Provider (VSP) soft switches 104 a, 104 b, 104 c (collectivelyreferred to as 104) using an Internet Protocol (IP) connection, mostcommonly over the Internet. The VoIP service provider's soft switch 104in turn communicates with a respective VoIP Positioning Center (VPC) 106a, 106 b, 106 c (collectively referred to as 106) using an appropriateIP connection. Each VSP requires use of their own VPC, as depicted inFIG. 5.

FIG. 6 shows in more detail conventional VoIP elements required by a VPCto interconnect a VoIP emergency E911 caller to a relevant public safetyaccess point (PSAP).

In particular, as shown in FIG. 6, each VPC 106 comprises its ownrespective route determination module 404, call delivery module 406, andprovisioning list 408.

A respective location information server (LIS) 108 services each of theVPCs 106. The LIS 108 is responsible for storing and providing access tothe subscriber location information needed for E9-1-1 call processing(as defined by the NENA VoIP Location Working Group).

A conventional VoIP Positioning Center (VPC) 106 is a system thatattempts to determine the appropriate or correct PSAP 114 that a VoIPemergency E911 call should be routed to based on the VoIP subscriber'sposition. The conventional VPC 106 also returns associated routinginstructions to the VoIP network. The conventional VPC 106 additionallyprovides the caller's location and the callback number to the relevantPSAP through the automatic location identifier (ALI) (The ALI is adatabase that accepts a PSAP query, and using that relates a specifictelephone number to a street address. In the case of an EmergencyServices Query Key (ESQK), the ALI database steers the query to theappropriate VPC and steers the response back to the PSAP. An ALI istypically owned by a LEC or a PSAP.)

Further as shown in FIG. 6, each VSP route the emergency 9-1-1 call,without location object added, to their VPC 106. The VPC must determinethe correct PSAP 114 (collectively represented by PSAP 114 a, 114 b and114 c) and route to it using the appropriate technology.

In a first scenario, the VPC 106 passes the 9-1-1 call to the PSAP 114 ausing an INVITE telephone number message, via a media gateway 110 thattranslates between the IP protocol of the INVITE message and a telephoneline interface, and interfaces with the public switched telephonenetwork (PSTN) 112.

In a second scenario, the VPC 106 passes the 9-1-1 call to the PSAP 114b using an INVITE S/R message, via an ESGW 120 and selective router 122.In this scenario, the selective router 122 is connected to the relevantPSAP 114 b via direct trunks.

In a third scenario, the VPC 106 passes the 9-1-1 call to the PSAP 114 cusing an INVITE PSAP message, via IP, to the PSAP 114 c.

In the second and third scenario, the ALI 126 must be inter-connectedwith each VPC 106 (a, b, c). Furthermore, each VPC is burdened withsupporting all the various ALI protocols: ve2, e2, PAM, legacy NENA,etc.

Thus, as can be appreciated, an Emergency call (e.g., 911, E911) mayrequire the involvement of one or more Response Centers (RCs), e.g.,Public Safety Access Point (PSAP) in addition to the RC that initiallyreceives the emergency call. This is because there is a possibility thatthe emergency call is received by a PSAP other than that which isassigned to the geographic region that the caller is currently locatedin.

Accordingly, the PSAP that initially answers the call may need totransfer the emergency call to the correct PSAP. During transfer of theemergency VoIP call, the original RC may or may not remain on the line,but for safety purposes will not likely want to disconnect or coldtransfer the emergency call. This is because errors may occur in thetransfer, resulting in valuable time lost. One cause of a faultytransfer of the E911 call would be that the VoIP user has not updatedthe location stored by the VPC, or quite simply that bad routing hasoccurred. Another cause would be that the nature of the emergencyrequires multiple parties to be involved (e.g., fire/police, police/FBI,ambulance/CDC, etc.).

Conventional solutions are based on tools that can be used to find thephone numbers of other emergency response centers. The ERC receiving thecall initially will perform a look-up for the correct response center,and may dial the identified correct response center, agency, etc., andtransfer the call via direct dial/public switched telephone network(PSTN.

One exemplary conventional solution is called an Intelligent EmergencyNetwork (IEN), available from Intrado Inc. of Longmont, Colo. However,such conventional solutions typically require the emergency responsecenter to know the direct dial lines of every PSAP, ESP, ERC, etc.nationally. Moreover, those lines may not always be staffed. Otherpotential problems would be caused if no automatic locationidentification (ALI) information is accessible or available.

There is a need for an architecture and methodology that both simplifiesthe complexity of a VoIP call transfers with respect to an emergencyresponse center such as a public safety access point (PSAP).

SUMMARY OF THE INVENTION

In accordance with the principles of the present invention, a method ofconnecting an emergency caller with an emergency response centercomprises establishing an emergency call conference. The emergencycaller is added to the established emergency call conference, and theemergency response center is added to the emergency call conference. Theemergency call is established after the emergency caller and theemergency response center are both added to the emergency callconference.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary architecture of a VoIP emergency callconference bridge application operating in a VoIP soft switch of a VoIPprovider to provide VoIP emergency call conferencing, in accordance withthe principles of the present invention.

FIG. 2 shows an exemplary message flow diagram of VoIP location based911 conferencing, in accordance with the principles of the presentinvention.

FIG. 3 shows an exemplary architecture of a VoIP conference bridgeapplication operating in a VoIP soft switch of a VoIP provider toprovide VoIP emergency call conferencing, in accordance with theprinciples of the present invention.

FIG. 4 shows an exemplary message flow diagram for establishing a VoIPlocation based conference, in accordance with the principles of thepresent invention.

FIG. 5 shows basic conventional VoIP elements required to interconnect aVoIP emergency E911 caller to a relevant public safety access point(PSAP).

FIG. 6 shows in more detail conventional VoIP elements required tointerconnect a VoIP emergency E911 caller to a relevant public safetyaccess point (PSAP).

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention handles emergency calls through the use of aconference bridge on a VoIP service provider's soft switch. The softswitch works with a VoIP positioning center (VPC) to obtain locationinformation, which may be gathered or confirmed by the initial recipientof the call, to ensure that appropriate participants to the emergencyconference call are Invited to join the call. With the present inventionin place, any number of emergency calls can be made, including anynumber of ERCs, PSAPs, ERPs, etc., (limited only by the number ofconference bridges that can be established in provisioned equipment,e.g., in the VoIP service provider's soft switch). Cold transfers can beavoided by Inviting participants to join a single emergency conferencerather than passing an original call from party to party (e.g., fromPSAP to police to ambulance, etc.) Moreover, the emergency call cansurvive as long as a participant remains in the emergency conferencecall, even after the original emergency caller hangs up.

FIG. 1 shows an exemplary architecture of a VoIP emergency callconference bridge application operating in a VoIP soft switch of a VoIPprovider to provide VoIP emergency call conferencing, in accordance withthe principles of the present invention.

In particular, as shown in FIG. 1, a user of a VoIP communicationsdevice 104 makes an emergency call (e.g., a 911 call). The VoIP serviceprovider of the VoIP communications device 104 receives the 911 call,and assigns it to an available VoIP emergency conference call bridge100. The soft switch 102 obtains location information relating to theVoIP communications device 104, either directly from the VoIPcommunications device 104 itself (e.g., if it includes a GPS device) orfrom a VoIP positioning center (VPC). The VoIP soft switch 102 comparesthe location information in a PSAP lookup database 800 to determine aninitial PSAP for the service area responsible for the location of theVoIP communications device 104. The PSAP lookup database provides anappropriate URL or other address information of the initial PSAP to theVoIP soft switch 102, which in turn addresses an Invite message 804(preferably including location information relating to the location ofthe VoIP communications device 104). The PSAP 810, in response, sendseither an Accept message or a Reject message to the soft switch 102 inresponse to the Invite message 804. Additional emergency servicesdepartments (e.g., police 812, fire 814, etc.) may be subsequently sentan Invite message to join the same VoIP emergency conference call.

Thus, the VoIP communication device 104 dials the appropriate emergencynumber (e.g., 911), and in response the VoIP service provider's softswitch 102 otherwise responsible for routing the user's calls insteadestablishes a VoIP conference bridge 100 and places the incomingemergency call into the VoIP conference bridge 100.

Although the initial emergency VoIP communication device 104 is a VoIPdevice, the soft switch 102 may additionally include interfaces to thePublic Switched Telephone Network (PSTN) to permit non-VoIP emergencyservice provider's to join into the VoIP conference bridge.

Alternatively, instead of automatically placing the initial VoIPemergency caller 104 into the established VoIP conference bridge 100,the VoIP soft switch 102 may instead Invite the initial VoIP emergencycaller 104 to join the conference call via the VoIP conference bridge100. In response, the initial VoIP emergency caller 104 presumablyaccepts the Invite message and joins the VoIP conference bridge 100.

At this point, the soft switch 102 may confirm location with the initialVoIP emergency caller 104 (if location information was provided with theinitial call from the VoIP communication device 104), or determineslocation from the subscriber's VPC, and captures the Location Object(LO).

The initial VoIP emergency caller 104 sends the LO and a 911 Invitemessage with an RC type (e.g., Fire Department, Homeland Security, etc.)to the soft switch 102 managing the VoIP conference bridge 100.

The soft switch 102 sends the LO and Invite information to the VPC,which identifies the proper additional conference participant(s) (e.g.,a PSAP, RC, first responder, other interested party, etc.) andcorresponding contact information, and invites the proper participantsto join the call.

The invited participant(s) can also invite other entities to join theVoIP emergency conference. While it is presumed that all participants inthe VoIP emergency conference call may participate in the call, it ispossible to include ‘listen only’ participants. For instance, a voiceand/or data recording line may be invited to the VoIP emergencyconference call to record any data and/or voice conversation.

FIG. 2 shows an exemplary message flow diagram of VoIP location based911 conferencing, in accordance with the principles of the presentinvention.

In particular, as shown in FIG. 2, an emergency call 712 (e.g., 911) isplaced from VoIP communications device 104.

In response, the VoIP soft switch establishing the VoIP emergencyconference call bridge transmits an emergency VoIP conference callInvite message (with or without a location object) 714 (or otherlocation request) to the VoIP Positioning Center (VPC) 701. Based on thelocation of the initiating VoIP emergency caller 104, the VPC pass atleast one Invite message using Internet Protocol (e.g., over theInternet) to interested third parties such as an initially contactedRC-1/PSAP 702, PSAP-2 703, PSAP-n 704, etc. The first emergency centercontacted (RC-1/PSAP 702) responds by verifying the location object andpassing the same, along with the Invite RC Type, to the soft switch 718.

As the emergency call progresses, other emergency responders may bebrought into the VoIP emergency conference call. For instance, the softswitch that manages the VoIP conference call bridge 100 initiates anInvite message with location object to the VPC 701, which in turntransmits an Invite message 722 to a subsequent emergency responsecenter (e.g., PSAP-2 703). That subsequent emergency response center 703responds by verifying/modifying the location object, and the Invite RCType, as shown in message 724.

The VoIP soft switch 102 may continue to invite additional emergencyresponders (or other parties) by passing an Invite message with locationobject through the VPC 701, which passes an Invite with location objectto the relevant other emergency responders 704.

As an example to explain advantages of the present invention, thescenario is given where an emergency 9-1-1 call is routed to a PSAPbased on a presumed or default location of the VoIP caller, but in factit turns out that the PSAP that receives the VoIP call is not thecorrect entity to handle emergency calls from the particular locationthat the VoIP caller is currently at. Such errors may occur, e.g., dueto the user not updating the SLDB, bad routing, etc. In this scenario,the initial VoIP communications device dials 9-1-1, a conference line isinitiated by the soft switch, an initially determined PSAP receives anInvite message to join the VoIP emergency conference bridge. The PSAPconfirms/determines the user's location, and in the given scenario woulddetermine that another PSAP is needed instead of or in addition to thePSAP on the line. In particular, the initial PSAP captures the LocationObject (LO) and either rejects the Invite to join the VoIP emergencyconference call (and is then removed from the conference bridge) orcontinues to participate in the VoIP emergency conference call (and sothen stays on the conference bridge). Either way, a 911 emergency callInvite message is sent with the LO to the soft switch managing the VoIPemergency conference bridge. The VoIP soft switch sends the LO to theVPC, which then identifies the proper PSAP based on the LO and initiatesan Invite message addressed over IP to the proper PSAP to join into theVoIP emergency conference call through the soft switch.

The VoIP conference bridge then joins the proper. PSAP to the VoIPemergency conference call with the initial VoIP emergency caller (andwith the initially contacted PSAP, if the initially contacted PSAPcontinues to participate in the call). In this manner, the initial VoIPemergency caller is kept on the line throughout the process, withpreferably no additional manual action or key entry required from theinitial emergency caller.

At the conclusion of the VoIP emergency call, the VoIP conference bridgeis closed.

In cases where the initial routing of the VoIP emergency call wascorrect, the VoIP conference bridge would still be used, and the initialtwo parties would participate in the VoIP emergency conference call(e.g., the initial VoIP emergency caller and the initially Invited RC orPSAP). If no other parties are invited, additional queries to the VoIPPositioning Center (VPC) would not be necessary. If additional partiesare invited, the soft switch would use location information and RC Typeinformation from the initial RC or PSAP to determine the identity ofother relevant RCs and/or PSAPs.

In general principle, FIG. 3 shows an exemplary architecture of a VoIPconference bridge application operating in a VoIP soft switch of a VoIPprovider to provide VoIP call conferencing, in accordance with theprinciples of the present invention.

In particular, as shown in FIG. 3, a VoIP communications device 104 isserviced by their service provider's soft switch 102. A positioningcenter 106 provides location data upon request from the soft switch 102.Other VoIP users 110, 112, 114 etc. are potential members of any givenconference.

Conference bridges 100 are implemented on the VoIP soft switch 102located, e.g., at the VoIP service provider's VoIP network.

While the VoIP soft switch 102 is preferably capable of beingprovisioned with as many VoIP conference bridges 100 as are required inany particular application, only one conference bridge 100 is shown inFIG. 3 for simplicity of explanation.

Also, while the conference bridge 100 is shown implemented in the softswitch 102, it can be embodied within another suitable network elementhaving an Internet Protocol (IP) type connection (e.g., TCP/IP) with theinitial user 104 as well as with the potential conferees 110, 112, 114.

In accordance with the principles of the present invention, locationinformation relating to the initial VoIP user 104 is passed to the VoIPconference bridge 100, either from the user's VoIP communication device104 or from their respective location server 106. The locationinformation is then compared by the VoIP soft switch 102 to find aninitial desired PSAP.

The VoIP soft switch 102 makes use of the location information and otherexisting data or user input (e.g., existing preferences on file on theSoft Switch 102, user entry through the keypad of the communicationsdevice 104, or voice response). Based on the location and user input,the VoIP conference bridge 100 identifies the desired PSAP to be askedor Invited to join the conference currently established by the initialVoIP user 104 on the conference bridge 100, and outputs an Invite orrequest message 204 to join that conference 100 to the specific URL(s),phone number(s) and/or other identifying address information relating toVoIP communications equipment 110, 112, 114 of the relevant PSAP.

The soft switch 102 may also maintain the attributes and rules fromother VoIP communication devices 110, 112, 114 etc. for receivingconference bridge calls, as well as the fixed location (e.g., a place ofbusiness) or the ability to query for a current location (e.g., formobile communication devices such as mobile phones) for each device.Based on this information, with or without other user input (e.g., toselect or prioritize among a list of available third parties), the softswitch 102 invites one or more other communication devices 110, 112,114, etc. to join the conference bridge. This creates a voice linkbetween the first user 104 and the other third parties 110, 112, 114without requiring the first user 104 to know the contact information orname of the third parties 110, 112, 114.

FIG. 4 shows an exemplary message flow diagram for establishing a VoIPlocation based conference, in accordance with the principles of thepresent invention.

In particular, as shown in FIG. 4, the initial VoIP user 104 sends arequest for conference bridge call to the soft switch 102. Preferablythe initial VoIP user 104 includes location information with theconference request call 201. However, as depicted in FIG. 3, locationinformation can be obtained from an appropriate positioning server 106if not available from the initial VoIP user 104.

Subsequent to the incoming conference call 201, a suitable PSAP (and/orother emergency services, including a recorder line) is determined andinvited with respective invite messages 204, 206.

In operation, the user's VoIP communication device 104 dials apre-determined phone number (or URL) of the emergency service (e.g.,911) to initiate a VoIP emergency conference bridge 100 on the relevantVoIP soft switch 102.

FIG. 3 shows use of a VoIP positioning center (VPC) 106. The VoIP softswitch 102 may receive the user's location information either from eachof the VoIP communication devices 104, 110, 112, 114 etc., or from theVPC 106.

The VoIP soft switch 102 preferably uses both the location informationof the initiating VoIP user 104, together with any profile criteria setfor a given conference bridge 100, to determine a suitable PSAP or otheremergency services entity to be sent INVITE messages inviting them tojoin the established VoIP emergency conference bridge 100.

The VoIP soft switch 102 invites one or more other VoIP communicationdevices 110, 112, 114, (relating to emergency services) to join the VoIPemergency conference bridge 100. This creates a voice link between theinitiating VoIP user 104 that initially called into the VoIP emergencyconference bridge 100, and the other potential, third party conferees110, 112, 114, etc., without requiring the initiating VoIP user 104 toknow the name or even the contact information of the other potential,third party emergency conferees 110, 112, 114, etc.

Upon receipt of an invite to a VoIP conference bridge 204, 206, thepotential other VoIP users 110, 112, 114, etc. (PSAPs) are preferablynotified similar to an incoming telephone call, e.g. with a ring signal,though it may be customized to be distinguished from the sound of anotherwise ordinary incoming phone call. For instance, a given uniquephone tone may be activated upon receipt of an invite 204, 206 to aconference bridge 100.

In accordance with the principles of the present invention, the VoIPcommunication device(s) 110, 112, 114 receiving invitations to join aVoIP emergency call conference 100 may be provided with a filter thatautomatically rejects any/all invite requests not meeting their ownspecific criteria (e.g., the first invited participant to accept theInvite message) maintained on their VoIP devices 110, 112, 114themselves, though such filtering may alternatively be performed at anetwork level, e.g., at the VoIP soft switch 102 or other centralizedlocation.

Benefits of the invention include that there is no effective limit tothe number of participants in the VoIP emergency conference call, thereare no cold transfers of a call as VoIP invitees enter or leave theconference bridge 100, and there is the ability to continue theconference call even after the initial VoIP user 104 making theemergency call disconnects.

The present invention has particular applicability with any/all VoIPusers, VoIP service providers, and Public Safety Access Points (PSAPs).

The invited VoIP users 110, 112, 114 may include a filter allowingthrough only acceptable Invite messages based on criteria established byor on the receiving VoIP communication devices 110, 112, 114.

The present invention allows VoIP users to efficiently and quickly findand invite their most appropriate responder to their emergency, withminimal user interaction. This is particularly helpful for mobile VoIPusers (e.g., while driving, walking, etc.) Moreover, there is noeffective limit to the number of participants in the conference call(within network hardware limits of the conference bridge itself). Thereis also no risk of cold transfers of a VoIP telephone call asparticipants aren't handled in point-to-point connections that aretransferred but rather join or exit an established conference at will.Furthermore, emergency personnel from various departments and locationsin the conference call can continue in the conference even after theinitial emergency caller disconnects.

Potential markets for the present invention include VoIP serviceproviders who may implement the inventive VoIP emergency conferencecalling as a value added services for users. VoIP location basedconferencing in accordance with the principles of the present inventionhas particular applicability with any/all VoIP users, VoIP serviceproviders, and Public Safety Access Points (PSAPs).

While the invention has been described with reference to the exemplaryembodiments thereof, those skilled in the art will be able to makevarious modifications to the described embodiments of the inventionwithout departing from the true spirit and scope of the invention.

1. A method of connecting an emergency caller with an emergency responsecenter, comprising: establishing an emergency call conference; addingsaid emergency caller to said established emergency call conference; andadding said emergency response center to said emergency call conference;wherein said emergency call is established after said emergency callerand said emergency response center are both added to said emergency callconference. 2-16. (canceled)